1. Field of the Invention
This invention generally relates to the field of wireless communications. More particularly, the present invention relates to a novel method of avoiding time-outs to sustain IPCP address negotiations.
2. Description of Related Art
Recent innovations in wireless communication and computer-related technologies, as well as the unprecedented growth of Internet subscribers, have paved the way for mobile computing. In fact, the popularity of mobile computing has placed greater demands on the current Internet infrastructure to provide mobile users with more support. A crucial part of meeting these demands and providing users with the necessary support is the use of Code Division Multiple Access (CDMA) technology in wireless communication systems.
CDMA is a digital radio-frequency (RF) channelization technique defined in the Telecommunications Industry Association/Electronics Industries Association Interim Standard-95 (TIA/EIA IS-95), entitled xe2x80x9cMOBILE STATION-BASE STATION COMPATIBILITY STANDARD FOR DUAL-MODE WIDEBAND SPREAD SPECTRUM CELLULAR SYSTEMxe2x80x9d, published in July 1993 and herein incorporated by reference. Wireless communication systems employing this technology assign a unique code to communication signals and spread these communication signals across a common (wideband) spread spectrum bandwidth. As long as the receiving apparatus in a CDMA system has the correct code, it can successfully detect and select its communication signal from the other signals concurrently transmitted over the same bandwidth. The use of CDMA produces an increase in system traffic capacity, improves overall call quality and noise reduction, and provides a reliable transport mechanism for data service traffic.
FIG. 1 illustrates the basic elements of such a wireless data communication system 100. Artisans of ordinary skill will readily appreciate that these elements, and their interfaces, may be modified, augmented, or subjected to various standards known in the art, without limiting their scope or function. System 100 allows a mobile terminal equipment, TE2 device 102 (e.g., the terminal equipment such as laptop or palmtop computer) to communicate with an Interworking Function (IWF) 108. System 100 includes a wireless communication device, MT2 device 104 (e.g., wireless telephone), and a Base Station/Mobile Switching Center (BS/MSC) 106. The IWF 108 serves as a gateway between the wireless network and other networks, such as the Public Switched Telephone Network or wireline packet data networks providing Internet-or Intranet-based access. An L interface couples IWF 108 to BS/MSC 106. Often the IWF 108 will be co-located with the BS/MSC 106. The TE2 device 102 is electronically coupled to the MT2 device 104 via the Rm interface. The MT2 device 104 communicates with the BS/MSC 106 via the wireless interface Um. The TE2 device 102 and the MT2 device 104 may be integrated into a single unit (e.g., MT0 device) or may be separated out, as in the case of an installed mobile phone unit in which a laptop is the TE2 device 102 and the transceiver is the MT2 device 104. It is important to note that, as indicated by FIG. 2, the combination of the TE2 device 102 and the MT2 device 104, whether integrated or separate, is generally referred to as a mobile station (MS) 103.
Other support is made possible by applying various well-known protocols to control, manage, or otherwise facilitate different aspects of wireless communications. For example, the life-blood of the Internet infrastructure, the Internet Protocol (IP), has been incorporated in many wireless communication services to accommodate packet-oriented services. The IP protocol specifies the addressing and routing of packets (datagrams) between host computers and is defined in Request For Comment 791 (RFC 791) entitled, xe2x80x9cINTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION,xe2x80x9d published September 1981.
The IP protocol is a network layer protocol that encapsulates data into IP packets for transmission. Addressing and routing information is affixed in the header of the packet. IP headers contain 32-bit addresses that identify the sending and receiving hosts. These addresses are used by intermediate routers to select a path through the network for the packet towards its ultimate destination at the intended address. Thus, the IP protocol allows packets originating at any Internet node in the world to be routed to any other Internet node in the world.
Another well-known protocol incorporated in wireless communications systems is the Point-to-Point Protocol (PPP) protocol, which provides, inter alia, Internet access. The PPP protocol is described in detail in Request for Comments 1661 (RFC 1661), entitled xe2x80x9cTHE POINT-TO-POINT PROTOCOL (PPP)xe2x80x9d, published July 1994.
Essentially, the PPP protocol specifies a method for transporting multiprotocol datagrams over point-to-point links and contains three main components: a method of encapsulating multi-protocol datagrams; a Link Control Protocol (LCP) for establishing, configuring, and testing a data link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
In an effort to provide a host of services on wireless communication systems, various standards have been developed to accommodate the wireless data transmission between the TE2 device 102 and the IWF 108. For example, the TIA/EIA IS707.5 standard, entitled xe2x80x9cDATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: PACKET DATA SERVICES,xe2x80x9d published February 1998, and herein incorporated by reference, defines requirements for support of packet data transmission capability on TIA/EIA IS95 systems and specifies a suite of packet data bearer services.
In particular, the IS-707.5 standard provides certain packet data service modes that may be used to communicate between the TE2 device 102 and IWF 108 via BS/MSC 106. In doing so, IS-707.5 introduces the Network Model, which provides a specific mode of operation. The Network Model represents the situation where a first PPP link is set up between the TE2 device 102 and the MT2 device 104, and a second PPP link, independent of the first, is set up between the MT2 device 104 and the IWF 108. This model makes the MT2 device 104 responsible for unframing any received PPP packets and re-framing them before forwarding them to their final destination as well as providing mobility management and network address management.
FIG. 2 illustrates the protocol stacks in each entity of the IS-707.5 Network Model. At the far left of FIG. 2 is a protocol stack, shown in conventional vertical format, depicting the protocol layers running on the TE2 device 102 (e.g., the mobile terminal, laptop or palmtop computer). The TE2 protocol stack is illustrated as being logically connected to the MT2 device 104 protocol stack over the Rm interface. The MT2 device 104, is illustrated as being logically connected to the BS/MSC 106 protocol stack over the Um interface. The BS/MSC 106 protocol stack is, in turn, shown as being logically connected to the IWF 108 protocol stack over the L interface.
As an illustration, the protocols depicted in FIG. 2, operate as follows: the PPP layer on the TE2102 device associated with the Rm interface (i.e., PPPR 208), encodes packets from the upper layer protocols 204, and the network layer IP protocol 206. The PPPR layer 208 then transmits the packets across the Rm interface using an applicable protocol, such as, for example, the TIA/EIA 232-F protocol 210, and the packets are received by the TIA/EIA-232-F-compatible port on the MT2 device 104. The TIA/EIA-232-F standard is defined in xe2x80x9cINTERFACE BETWEEN DATA TERMINAL EQUIPMENT AND DATA CIRCUIT-TERMINATING EQUIPMENT EMPLOYING SERIAL BINARY DATA INTERCHANGExe2x80x9d, published in October 1997 and herein incorporated by reference. It is to be understood that other standards or protocols known to artisans of ordinary skill in the art may be used to define the transmission across the Rm interface. For example, other applicable Rm. interface standards include, the xe2x80x9cUNIVERSAL SERIAL BUS (USB) SPECIFICATION, Revision 1.1xe2x80x9d, published in September 1998, and the xe2x80x9cBLUETOOTH SPECIFICATION VERSION 1.0A CORE, published in July 1999, both incorporated by reference.
The TIA/EIA 232-F protocol 212 on the MT2 device 104 receives the packets from the TE2 device 102 and passes them to the PPPR layer 213 of the MT2 device 104. The PPPR layer 213 unframes the packets encapsulated in the PPP frames and typically, when a data connection is up, layer 213 transfers the packets to the PPP layer associated with the Um. interface (i.e., PPPU layer 217). PPPU layer 217 formats the packets in PPP frames for transmission to a PPPU peer located in the IWF 108. The Radio Link Protocol (RLP) 216 and IS-95 protocol 214, both of which are well known in the art, are used to transmit the packet-encapsulated PPP frames to the BS/MSC 106 over the Um interface. The RLP protocol 216 is defined in the IS-707.2 standard, entitled xe2x80x9cDATA SERVICE OPTIONS FOR WIDEBAND SPREAD SPECTRUM SYSTEMS: RADIO LINK PROTOCOLxe2x80x9d, published in February 1998 and the IS-95 protocol is defined in the IS-95 standard identified above.
As stated above, the PPPR protocol 213 transfers the packets to the PPPU protocol 217 when a data link connection is established. RFC 1661 provides that Link Control Protocol (LCP) packets must be exchanged and negotiated over each PPP link (i.e., PPPR and PPPU ) in order to establish, configure, and test the data link connection.
Once the LCP packets are exchanged, the link options negotiated, and the data link connection established, a network layer connection must be established between the TE2 device 102 and the IWF 108. Such a connection employs protocols 206, 212, 218, 230, that include, for example, the IP protocol. The negotiating, configuring, enabling, and disabling of the IP protocol on both ends of the PPP links is provided by the well-known Internet Protocol Control Protocol (IPCP). IPCP is a part of a family of Network Control Protocols (NCPs) included in the PPP protocol and is described in Request for Comment (RFC) 1332, xe2x80x9cTHE PPP INTERNET PROTOCOL CONTROL PROTOCOL (IPCP)xe2x80x9d, published in May 1992.
The IPCP protocol employs the standard PPP Configure-Request, Configure-Ack, and Configure-Nak messages to negotiate various options, including the request and designation of IP addresses. IPCP provides that a requester requesting an IP address, generates a Configure-Request message, which contains a particular address. If the particular IP address is acceptable, a Configuration-Ack message is sent by a peer to the requester. If the particular IP address is not acceptable, then the peer sends a Configure-Nak message containing a suggested IP address. The requester then transmits a new Configure-Request message with the suggested IP address and the peer responds with a Configure-Ack.
It is only possible to assign single IP address across the PPPU and PPPR links as there is no mechanism in IPCP to assign more than one address. This means that the IP address that is assigned from the IWF over PPPU, must further be assigned to the TE2 over PPPR. In the Network Model, while IPCP address negotiations can occur separately for both the Rm interface and the Um interface. As such, the MT2 device 104 must first negotiate an IP address over the Um interface with the IWF 108 at one end of the PPPU link, before the address can be assigned to the TE2 device 102 at the other end of the PPPR link.
The consummation of IPCP address negotiations may be obstructed, however, by operational delays. For example, such delays can occur if the link between the MT2 device 104 and the IWF 108 is slower than the link between the TE2 device 102 and the MT2 device 104. As such, there exists a possibility that IPCP address negotiations are reached faster on the Rm link than on the Um link. The TE2 device 102 may, therefore, request an IP address from the MT2 device 104, which cannot be granted because the MT2 device 104 has not completed the requisite address negotiations on the Um link to render an IP address from the IWF 108. Although the TE2 device 102 is capable of waiting for the MT2 device 104 to eventually render an IP address, there are implementation-specific time-outs on the TE2 device 102, which can cause the TE2 device 102 to abort the IP address request, and therefor PPP negotiations altogether.
Another example of operational delays occurs when the IWF 108 has to get the IP address, which will eventually be assigned to the TE2 device 102, from some other entity before it can pass it on to the MT2 device 104. In doing so, it may take several seconds before the MT2 device 104 receives the IP address.
By way of example, it is noted that some applications running on the TE2 device 102 allow the TE2 device 102 to generate Configure-Request messages every 3 seconds for 3 attempts before the TE2 device 102 times out. In such cases, if it takes more than a total of 9 seconds to receive an IP address, the TE2 device 102 aborts the address request. Clearly, either of the two scenarios noted above can generate delays that can lead to the TE2 device 102 to abort prematurely.
Therefore, what is needed is a novel method of avoiding time-outs to sustain IPCP address negotiations.
The present invention addresses the need identified above by providing a novel method of avoiding time-outs to sustain IPCP negotiations.
Methods consistent with the principles of the present invention as embodied and broadly described herein include a communication device receiving a message requesting an IP address, such as a Config-Request message, from a terminal device which is coupled to the communication device. The communication device then determines whether it has received an assigned IP address from a peer (i.e. IWF) in response to the IP address request message. In response to determining that the communication device has not received the assigned IP address from the IWF, the communication device transmits a message with an arbitrary IP address, such as a Configure-Nak message, to the terminal device. The arbitrary IP address contained within the message will be rejected by the communication device, which triggers the terminal device to keep transmitting additional IP address request messages until the communication device has received the assigned IP address.